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Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Verfahren zum Verteilen einer Gruppennachricht in einem Funkkommunikationssystem sowie zugehdriges 
Funkkommunikation ssy st e m 



Zum Verteilen einer Gruppennachricht (GN1) in einem 
Funkkommunikationsnetz (FN2) wird durch mindestens 
ein Multicast-Center (MCC) an die Mitglieder-Teilnehmer- 
gerate einer ausgewahlten Gruppe (A) die zu verteilende 
Gruppenachricht (GN1) lediglich auf einem gemeinsa- 
men Ubertragungspfad (GP) an mindestens eine uberge- 
ordnete Funknetzwerkkontrolleinheit (SGSN1) gesendet. 
Dabei werden mittels mindestens einer Speichervorrich- 
tung (SP1) die aktuell zugehorigen, zu benachrichtigen- 
den Teilnehmergerate (UE1, UE2, UE4, UE5) der jeweils 
ausgewahlten Gruppe (A) ermittelt und diese der uberge- 
ordneten Funknetzwerkkontrolleinheit (SGSN1) mitge- 
teilt. 

"Verteilung von M u It i cast- Nach rich ten im UMTS". 
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Beschreibung 

Verfahren zum Verteilen einer Gruppennachricht in einem 
Funkkommunikationssystem sowie zugehoriges Funkkom- 
munikationssystem 

[0001] Bei vielen in modernen Mobilfunksystemen ange- 
botenen Diensten und Anwendungen ist es wiinschenswert, 
Nachrichten nicht nur zu einem, sondern zu zwei oder meh- 
reren Mobilfunkteilnehmern zu iibertragen. Beispiele fur 
sole he Dienste und Anwendungen sind insbesondere News- 
Groups, Videokonferenzen, Video-On-Demand, verteilte 
Anwendungen, usw. 

[0002] Eine Aufgabe der Erfindung ist es, einen Weg auf- 
zuzeigen, wie solche Gruppen-Nachrichten an eine Vielzahl 
von Teilnehmergeraten eines Funkkommunikations systems, 
insbesondere Mobilfunknetzes, in emzienter Weise iibertra- 
gen werden konncn. Diese Aufgabe wird durch folgendcs 
erfindungsgemaBe Verfahren gelost: Verfahren zum Vertei- 
len einer Gruppennachricht an mindestens eine Gruppe von 
Teilnehmergeraten eines Funkkommunikationssystems, wo- 
bei in mindestens einer Speichervorrichtung die ein oder 
mehreren Teilnehmergerate der jeweiligen Gruppe unter ei- 
ner gemeinsamen Identifizierungsadresse abgelegt worden 
sind und dort fordaufend aklualisierl werden, wobei zur Ver- 
teilung der jeweiligen Gruppennachricht durch mindestens 
ein Multicast-Center an die Mitglieder- Teilnehmergerate ei- 
ner ausgewahlten Gruppe diese zu verteilende Gruppen- 
nachricht lediglich tiber einen gemeinsamen Ubertragungs- 
pfad an mindestens eine iibergeordnete Funknetzwerk-Kon- 
trolleinheit gesendet wird, mittels der Speichervorrichtung 
die aktuell zugehorigen, zu benachrichtigenden Teilnehmer- 
gerate dieser ausgewahlten Gruppe ermittelt, und diese der 
ubergeordneten Funknetzwerk-Kontrolleinheit mitgeteilt 
werden, und wobei dann von dieser ubergeordneten Funk- 35 
netzwerk-Kontrolleinheit mindestens ein Ubertragungspfad 
zur Verteilung der Gruppennachricht an die ermittelten Mit- 
glieds-Teilnehmergerate der ausgewahlten Gruppe unter Zu- 
hilfenahme einer oder mehrerer untergeordneter Funknetz- 
werk-Kontrolleinheiten bereitgestellt wird. 40 
[0003] Dadurch ist eine effiziente und einfache Verteilung 
von Gruppen-Nachrichten an die verschiedenen Teilneh- 
mergerate der jeweilig ausgewahlten Gruppe ermoglicht. 
[0004] Die Erfindung betrifft weiterhin ein Funkkommu- 
nikations system zum Verteilen einer Gruppennachricht an 45 
mindestens eine Gruppe von Teilnehmergeraten, insbeson- 
dere nach einem der vorhergehenden Anspriiche, wobei 
mindestens eine Speichervorrichtung vorgesehen ist, in der 
ein oder mehrere Teilnehmergerate der jeweiligen Gruppe 
unter einer gemeinsamen Identifizierungsadresse ablegbar 50 
und dort fortlaufend aktualisierbar sind, wobei mindestens 
ein Multicast-Center vorgesehen ist, mit dessen Hilfe bei ei- 
nem Verteilungswunsch eine neue Gruppennachricht an die 
Mitgheds-Teilnehmergerate einer ausgewahlten Gruppe auf 
einem gemeinsamen Ubertragungspfad an mindestens eine 55 
iibergeordnete Funknetzwerkkontrolleinheit sendbar ist, 
wobei die Speichervorrichtung derart ausgebildet ist, dass 
die aktuell zugehorigen, zu benachrichtigenden Teilnehmer- 
gerate dieser ausgewahlten Gruppe ermittelbar, und diese 
der ubergeordneten Funknetzwerkkontrolleinheit mitteilbar 60 
sind, und wobei die iibergeordnete Funknetzwerkkontroll- 
einheit und/oder ihre jeweilig in Wirkverbindung stehende 
untergeordnete Funknetzwerkkontrolleinheit derart ausge- 
bildet sind, dass mindestens ein Ubertragungspfad von die- 
ser ubergeordneten Funknetzwerkkontrolleinheit zur Vcrtci- 65 
lung der Gruppennachricht an die ermittelten Mitglieds- 
Teilnehmergerate bereitstellbar ist. 

[0005] Sonstige Weiterbildungen der Erfindung sind in 



den Unteranspruchen wiedergegeben. 

[0006] Die Erfindung und ihre Weiterbildungen werden 
nachfolgend anhand von Zeichnungen naher erlautert. 
[0007] Es zeigen: 
5 [0008] Fig. 1 in schematischer Darstellung die prinzipielie 
Architektur eines Mobilfunksystems, 
[0009] Fig. 2 in schematischer Darstellung den Aufbau ei- 
nes Funkkommunikationssystems, das zur Durchfuhrung 
des erfindungsgemaBen Verfahrens zusatzlich zum Mobil- 
10 funksystem von Fig. 1 mindestens ein Multicast-Center zur 
Verteilung von Multicast-Nachrichten aufweist, 
[0010] Fig. 3 mit 5 in schematischer Darstellung den 
schrittweisen Aufbau eines PDP-Contextes, wenn fiir ein 
bestimmtes Teilnehmergerat des Funkkommunikationssy- 
15 stems nach Fig. 1 bzw. 2 ein Datenpaket netzwerkseitig 
ubermittelt werden soil, 

[0011] Fig. 6 in schemauscher Darstellung verschiedene 
Pakctwcgc im Funkkommunikations system nach Fig. 1 fur 
mehrere zu benachrichtigende Teilnehmergerate, an die 
20 diesselbe Nachricht nach Aufbau von Ubertragungsverbin- 
dungen entsprechend den Fig. 3 mit 5 jeweils einzeln iiber- 
mittelt wird, 

[0012] Fig. 7 in schematischer Darstellung Paketwege im 
erfindungsgemaBen Funkkommunikationssystem nach Fig. 
25 2 bei Anwendung des Uberu-agungswegauibaus enlspre- 
chend den Fig. 3 mit 5 fur das Mobilf unksy stem nach Fig. 1 , 
[0013] Fig. 8 mit 10 in schematischer Darstellung den 
schrittweisen Aufbau von Ubertragungsverbindungen zur 
Ubertragung von Multicast-Nachrichten an eine ausge- 
30 wahlte Gruppe von Teilnehmergeraten nach einer ersten Va- 
riante des erfindungsgemaBen Verfahrens mit Hilfe des 
Funkkommunikationssystems nach Fig. 2, 
[0014] Fig. 1 1 in schematischer Darstellung den detaillier- 
ten Ablauf eines Verbindungsaufbaus fur ein einzelnes Teil- 
nehmergerat nach dem erfindungsgemaBen Verfahren ent- 
sprechend den Fig. 8 mit 10, 

[0015] Fig. 12 in schematischer Darstellung eine weitere 
Variante des erfindungsgemaBen Verfahrens, 
[0016] Fig. 13 in schematischer Darstellung den detail- 
lierten Verbindungsaufbau fiir ein bestimmtes Teilnehmer- 
gerat, 

[0017] Fig. 14 in schematischer Darstellung den Regi- 
strierungsprozess eines Teilnehmergerats im Funkkommu- 
nikationssystem nach Fig. 2, um eine Multicast-Nachricht 
nach dem erfindungsgemaBen Verfahren empfangen zu kon- 
nen, 

[0018] Fig. 15 in schematischer Darstellung die Kompo- 
nenten einer Packlet Switched Domaine, die beim Transport 
von Paketdaten im UMTS-Network beteiligt sind, 
[0019] Fig. 16, 17 schematisch das prinzipiellen Verfah- 
ren zur Verteilung von Gruppennachrichten nach dem Inter- 
net Group Managment Protokoll, 

[0020] Fig. 18 schematisch das prinzipielie Verteilungs- 
verfahren fiir Gruppennachrichten nach dem Reverse Path 
Multicasting Prinzip, 

[0021] Fig. 19 in schematischer Darstellung die Signali- 
sierung fiir ein bestimmtes Teilnehmergerat zum Eintrag sei- 
ner Multicast-Gruppenzugehorigkeit in eine Datenbank zur 
Durchfuhrung des erfindungsgemaBen Verfahrens mit dem 
Funkkommunikationssystem nach Fig. 2, 
[0022] Fig. 20 in schematischer Darstellung eine erste Va- 
riante einer Multicast -Context Aktivierung zur Verteilung 
von Multicast-Nachrichten nach dem erfindungsgemaBen 
Verfahren mit Hilfe des Funkkommunikationssystems nach 
Fig. 2, 

[0023] Fig. 21, 22 jeweils in schematischer Darstellung 
modifizierte Multicast -Context Aktivierungen zur Durch- 
fuhrung des erfindungsgemaBen Verfahrens, 



DE 100 64 107 A 1 



[0024] Fig. 23 mit 25 drei verschiedene Varianten des er- 
findungsgemafien Multicast- Verfahrens zur Veneilung von 
Multicast.Nachrichten, 

[0025] Fig. 26 eine Variante des Mulricast-Verfahrens 
nach Fig. 23 

[0026] Fig. 27 eine Variante des Multicast- Verfahrens 
nach Fig. 24, und 

[0027] Fig. 28 eine Variante des Mulricast-Verfahrens 
nach Fig. 25. 

[0028] Elemente rnit gleicher Funktion und Wirkungs- 
weise sind in den Fig. 1 mit 28 jeweils mit denselben Be- 
zugszeichen versehen. 

[0029] In modernen Mobilfunksystemen wie z. B. nach 
dem UMTS (Universal Mobil Communication System), 
GPRS (General Paket Radio Service), EDGE (Enhanced 
Data Rates for GSM Environment) ist es wiinschenswert, 
Nachrichten nicht nur zu einem einzeinen, sondem zu zwei 
odcr mchrcrcn Mobilfunktcilnchmcm zu iibcrtragen. Bci- 
spiele fiir solche Dienste und Anwendungen sind News- 
Groups, Video-Konferenzen, Video-On-DemanD, verteilte 
Anwendungen usw. 

[0030] Bei der Ubertragung der Nachrichten zu den ver- 
schiedenen Teilnehmern ist es moglich, jedem Empfanger 
separat eine Kopie der Daten zuzusenden. Diese Vorgehens- 
weise isl zwar einfach zu implemenueren, fur groBe Grup- 
pen von Teilnehmergeraten jedoch zu aufwendig. Da die 
selbe Nachricht uber N (N = Anzahl der Empfanger der 
Nachricht) Einzelverbindungen (= Unicast-Verbindungen) 
ubertragen und dabei mehrfach uber gemeinsame Verbin- 
dungswege gesendet wird, bendtigt dieses Verfahren eine zu 
none Bandbreite. 

[0031] Eine bessere Moglichkeit bietet demgegenuber die 
sog. Multicast-Ubertragung. Hierbei werden die verschiede- 
nen Teilnehmergerate, denen die selbe Nachricht ubermittelt 
werden soil, zu einer Gruppe (= Multicast-Gruppe) zusam- 
mengefasst und dieser eine gemeinsame Identifizierungs- 
adresse (Multicast- Adresse) zugeordnet. Auf diese Weise ist 
es nicht. erforderlich. dass der jeweilige Sender weiB, wie 
viele und welche Empfanger sich hinter der Multicast- 
Adresse verbergen. Es ist vielmehr ausreichend fur den je- 
weiligen Sender, lediglich den Namen bzw. die Adresse der 
zu benachrichtigenden Multicast-Gruppe zu kennen. Die zu 
ubertragenden Daten werden daraufhin nur einmal an diese 
Multicast- Adresse versendet. 

[0032] Problematisch fur das Verteilen solcher Multicast- 
Nachrichten ist. hierbei allerdings insbesondere die Verwal- 
tung derMulticast-Gruppen sowie die Wegwahl (= Routing) 
der Mult icast-Nachrich ten zu den einzeinen Teilnehmerge- 
raten der Multicast-Gruppen. Die Erfassung der zu einer 
Multicast-Gruppe gehorenden Teilnehmer ist insbesondere 
im Hinblick darauf problematisch, dass zu jedem Zeitpunkt 
neue Teilnehmergerate zu dieser Multicast-Gruppe beitre- 
ten, aber auch Mitglieder der jeweiligen Multicast-Gruppe 
wieder austreten konnen. 

[0033] Im Rahmen der Erfindung wird beispielhaft im fol- 
genden auf die Komponenten der packetswitehed Domain 
eine UMTS-Mobilfunknetzes FN1 eingegangen. Die Funk- 
tion und Wirkungsweise dessen Komponenten werden 
nachfolgend anhand von Fig. 15 naher erlautert: 
Ein Teilnehmer-Endgerat wie z. B. UE (User Equipment) ist 
uber eine Luftschnitts telle Uu (Uu-Interface) mit einer Ba- 
sisstation Node B verbunden. Diese Node B ist uber eine 
Festnetzverbindung Iub mit einem RNC (Radio Network 
Controller) als erste Funknetzwerkkontrolleinheit verbun- 
den, die die Rcssourccn der Luftschnittstelle kontrollicrt 
und verteilt. Der RNC wiederum kann eine oder niehrere 
Basisstationen versorgen. Das Teilsystem aus mindestens ei- 
nem Radio Network Controller und entsprechend zugehori- 



gen Basisstationen wird im allgemeinen als Radio Network 
Subsystem RNS bezeichnet, was in der Figur gestrichelt 
umrahmt angedeutet ist. Fiir die paketvermit.telte Ubertra- 
gung von z. B. IP-Paketen aus dem Internet TP zu einem ein- 

5 zelnen Teilnehmergerat. wie z. B. UE ist mindestens einer 
der Radio Network Controller wie z. B. RNC uber eine Fest- 
netzverbindung Iu mit einer hoheren Funknetzwerkkontroll- 
einheit SGSN, insbesondere im UMTS-Standard rnit einer 
sog. Serving GPRS Support Node, verbunden. Fiir eine 

10 Ubertragung von Daten aus einem fremden Paketdatennetz, 
wie hier beispielsweise dem Internet IP, ist die iibergeord- 
nete Funknetzwerkkontrolleinheit SGSN vorzugsweise iiber 
eine Festnetzverbindung Gn mil mindestens einem Gateway 
GGSN, insbesondere einem Gateway GPRS Support Node, 

15 verbunden. Dieses Gateway GGSN realisiert den Zugangs- 
punkt zu einem fremden Paketdatennetz. Uber eine Fest- 
netzverbindung Gi ist hier im Ausfuhrungsbeispiel von Fig. 
15 das Gateway GGSN mit einem Scrvcrr im Internet IP 
verbunden. Informationen fur das Managment der mobilen 

20 Teilnehmer konnen von Gateway GGSN uber eine Festnetz- 
verbindung Gc und von der hoheren Netzwerkeinheit SGSN 
iiber eine Festnetzverbindung Gr von einer zentral gefuhrten 
Datenbank HLR insbesondere dem sog. Home Location Re- 
gister abgefragt werden. Die hohere Funknetzwerkkontroll- 

25 einheil SGSN erfragl voui Home Location Register HLR 
nutzerspezifische Informationen wie z. B. zur Authentifizie- 
rung eines Teilnehmers. Desweiteren ist die hohere Kon- 
trolleinheit SGSN vorzugsweise verantwortlich fur einen 
Verbindungsaufbau zwischen dem jeweiligen Teilnehmer- 

30 gerat und einem fremden Paketdatennetz wie hier z. B. IP. 
[0034] Sollen Paketdaten aus dem externen Paketdaten- 
netz zum Funknetzwerk ubertragen werden, so gelangen 
diese zuerst zum Gateway GGSN, das beim Home Location 
Register HLR die jeweilig zustandige hohere Funknetz- 

35 werk-Kontrolleinheit SGSN erfragt. Dieser Gateway GGSN 
teilt nun der hoheren Funknetzwerk-Kontrolleinheit SGSN 
mit, dass Daten fur das entsprechende Teilnehmergerat vor- 
liegen. Die hoherer Funknetzwerk-Kontrolleinheit SGSN 
veranlasst daraufhin den Aufbau der Verbindungen zwi- 

40 schen dem zu benachrichtigenden Teilnehmergerat. UE und 
dem externen Netzwerk IP. 

[0035] Im Rahmen der Erfindung wird dabei unter einem 
Teilnehmergerat (User Equipment) als Komponente eines 
Funkkommunikations systems vorzugsweise ein mobiles 

45 Endgerat verstanden. Dieses ist z.B. im UMTS-Standard 
insbesondere uber die Luftschnittstelle Uu (Uu-Interface) 
mit dem sog. UTRAN (UMTS Terrestrial Radio Access 
Network) verbunden. Es enthalt das UMTS Subscriber 
Identity Modul (USIM), indem (ahnlich wie in der SIM im 

50 GSM-Netz) Identifizierungsdaten, die das Teilnehmergerat 
zur Registrierung und Teilnahme im UMTS-Netz berechti- 
gen, gespeichert sind. 

[0036] Eine Basisstarion (Node B) ist eine Funknetzwerk- 
Komponente, die fiir die Versorgung einer bzw. mehrerer 
55 Funkzellen zustandig ist. Mittels einer Basisstation erfolgt 
die Funkkommunikation uber die Luftschnittstelle mit dem 
jeweiligen Teilnehmergerat in derFunkzelle dieser Basissta- 
tion. 

[0037] Unter Radio Network Controller wird im Rahmen 
60 der Erfindung eine erste, untergeordnete Funknetzwerk- 
Kontrolleinheit verstanden, mit deren Hilfe die Ressourcen 
der Luftschnittstelle zwischen der jeweiligen Basisstation 
und den etwaigen Teilnehmergeraten in deren Funkzelle 
kontrolliert wird. Ein Radio Network Controller versorgt 
65 und kontrollicrt vorzugsweise cin odcr mchrcrc Basissta- 
tionen. Das Teilsystem aus einem Radio Network Controller 
wie z. B. RNC in Fig. 15 und einem oder mehreren Basissta- 
tionen wird als Radio Network Subsystem RNS bezeichnet, 
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was in der Fig. 15 durch eine gestrichelte Umrahmen ange- 
deutet ist. Dieses Teilsystem ist. durch das Iu-Interface mit 
niindestens einer hoheren Netzwerkkontrolleinheit wie z. B. 
SGSN in Fig. 15 verhunden. 

[00381 GPRS Support Nodes wie z. B. SGSN bilden die 5 
Schnittstelle zwischen dem Funksystem und einem Festnetz 
fur vorzugsweise paketvermittelte Services (PDN). Ein 
GPRS Support Node ruhrt aiie notwendigen Funktionen 
aus, um den Transport von Datenpaketen vom extern en 
PDN zum End-Teilnehmergerat, insbesondere zur Mobilsta- 10 
tion, und umgekehrt zu gewahrleisten. Z. B. im UMTS- 
GPRS-Netzwerk gibt es vorzugsweise 2 verschiedene 
GPRS Support Nodes (GSNs): den SGSN (Serving GSN) 
und den GGSN (Gateway GSN). 

[0039] Der SGSN ist derjenige Knoten, der die Teilneh- 15 
mergerate, insbesondere Mobilfunkstationen einer ihm zu- 
geordneten Region (SGSN Area) versorgt. Er verfolgt den 
Aufcnthaltsort dcs jcwciligcn Tcilnchmcrgcrats, fuhrt Si- 
cherheitsfunktionen und Zugriffskontrollen aus (Authenti- 
cation, cipher setting procedures und ahnliches). Ein SGSN 20 
besitzt Routing/Traffic-Managment-Funktionen und reali- 
siert die Schnittstelle zum GGSN (Gn) Access Network 
(Gb) und zu anderen PLMNs (Gp) (public land mobile net- 
works). Die Location Register Funktion des SGSN speichert 
neben den Teilnehiner Regislrierungsinfonnationen (IMSI, 25 
temporare Identitaten, PDP Adressen (packet data protocol) 
auch sogenannte Location Informationen, die benotigt wer- 
den, um eine Paketdatenubertragung aufzubauen bzw. zu 
beenden. 

[0040] Die Location Information kann je nach Modus der 30 
Mobilstation (MS) entweder die Cell- oder die Routing- 
Area sein, wo die MS derzeit registriert ist. Desweiteren 
werden aber auch die VLR-Nummer des verbundenen VLR 
(visitor location register) und die Adressen jedes GGSN ge- 
speichert, fur den ein aktiver PDP Context (siehe untenste- 35 
henden Abschnitt "Ubertragung von Paketdaten im UMTS") 
besteht. 

[0041] Desweiteren steuert der SGSN das Mobility Ma- 
nagement (mm), das genutzt wird, um den aktuellen Aufent- 
haltsort einer MS zu besummen. Auf der gleichen Protokoll- 40 
ebene zum Mobility Management existiert das Session Ma- 
nagement (SM), welches fur die Aktivierung und Deaktivie- 
rung des eben genannten PDP Contextes im SGSN sowie im 
GGSN zustandig ist. 

[0042] Uber das Gr-Interface tauschen SGSN und HLR 45 
Informationen aus. 

[0043] Der GGSN ist der Knoten, der den Kontakt (Inter- 
working) zwischen einem UMTS PLMN und einem Paket- 
daten Netzwerk (PDN) errnoglicht. Die Datenaustausch er- 
folgt iiber das Gi-Interface (Fig. 15). Der GGSN beinhaltet 50 
die Routing Informationen fiir die im PLMN erreichbaren 
UMTS Teilnehmer. Die Routing Informationen dienen der 
Kontaktierung des jeweiligen SGSN, in dessen Versor- 
gungsbereich (SGSN Area) sich eine bestimmte MS rao- 
mentan befindet. Um diesen SGSN zu kontaktieren, wird 55 
dessen Adresse als Location Information zweckmaBiger- 
weise gespeichert. 

[0044] Aufenthaltsinformationen iiber eine MS konnen 
iiber das Gc-Interface vom HLR abgefragt werden. 

60 

Home Location Register (HLR) 

[0045] Das HLR besteht aus einer Datenbank, die fiir das 
Management der mobilen Teilnehmer verantwortlich ist 
Ein PLMN (Public Land Mobile Network) kann cin oder 65 
mehrere HLRs beinhalten. Dies ist abhangig von der Anzahl 
der mobilen Teilnehmer, der Kapazitat des Equipments und 
von der Organisation des Netzwerkes. Die folgenden Arten 
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von Informationen werden hier gespeichert: 

- Anmeldungsinformationen der Teilnehmer 

- Hinige Location Informationen ermoglichen die Ab- 
rechnung und das Routing von Gesprachen zu dem 
MSG (Mobile-services Switching Center), bei dem die 
MS (Mobile Station) registriert ist (z. B. die MS Roa- 
ming Number, die VLR (Visitor Location Register) 
Number, die MSC Number, die Local MS Identity). 

[0046] Sofem GPRS unterstutzt wird, werden Location 
Informationen gespeichert, die die Abrechnung und das 
Routing von Nachrichten im SGSN (Serving GPRS Support 
Node) ermoglichen, an dem die MS gegenwartig angemel- 
det ist (z. B. die SGSN Number). Unterschiedliche Typen 
von Identifizierungen sind mit jeder Anmeldung einer MS 
verbunden und werden im HLR gespeichert: 

- International Mobile Subscriber Identity (IMSI) 

- Eine oder mehrere Mobile Station International 
ISDN numbers (MSISDN) 

- Keine, eine oder mehrere Packet Data Protocol 
(PDP) Adressen (IP Adressen) 

[0047] Es wird immer niindestens eine IdentilaL, gelxennl 
von der IMSI, mit einer MS Anmeldung ubergeben und im 
HLR gespeichert. Die IMSI oder die MSISDN konnen als 
Kennung fur den Zugang zu den Informationen des HLR fur 
die "mobile Anmeldung" genutzt werden. Die HLR-Daten- 
bank enthalt auch andere Informationen, wie z. B.: 

- Teleservices und Ubermittlerser vices, Anmeldein- 
formationen 

Serviceeinschriinkungen (z. B. begrenztes Roaming) 

- eine Liste aller Gruppen IDs, welche die Teilnehmer 
zum Aufbau einer Voice Group oder eines Broadcast 
Calls berechtigen 

- Informationen daruber, wenn es einem GGSN (Gate- 
way GPRS Support Node) erlaubt ist, dynamisch ei- 
nem Teilnehmer eine PDP Adresse zuzuweisen 

- Optional zusatzliche Services 



Home Subscriber Server (HSS) 

[0048] Das HSS enthalt LCS subscription data und Rou- 
ting-Informationen. Fiir umherschweifende (roaming) UEs 
kann das HSS in verse hiedenen PLMNs sein. 
[0049] Dieses Netzwerkelement ist eine Erweiterung des 
HLR fur das zukiinftige AU-IP-Netzwerk. 
[0050] Bevor Paketdaten (hier im Ausfuhrungsbeispiel 
IP-Pakete) zwischen beispielsweise einem Server im Inter- 
net EP und einem End-Teilnehmergerat wie z. B. UE (ver- 
gleiche Fig. 15) ubertragen werden konnen, wird vom Teil- 
nehmergerat UE zweckmaBigerweise ein sog. PDP Context 
(Paket Data Protokoll Context) aufgebaut, mit dessen Hilfe 
eine Verbindung zum Internet TP hergestellt wird. Ein PDP 
Context beschreibt dabei den Pfad durch das jeweilige Netz- 
werk, insbesondere UMTS -Netzwerk, und macht diesen in 
den Netzelementen UE, SGSN, GGSN bekannt. Erst darauf- 
hin kann eine Verbindung aufgebaut werden, iiber die dann 
die Paketdaten (im UMTS IP-Pakete) ubertragen werden. 
[0051] Im Rahmen dieser Erfindung wird haufig der Be- 
griff Bearer verwendet. Allgemein beschreibt der Begriff 
Bearer (Tragcr) cincn Pfad zur Ubertragung von Informatio- 
nen. Dieser ist insbesondere definiert durch seine Kapazitat, 
Laufzeitverzogerung und Bitfehlerrate. Die Schnittstelle 
zwischen dem jeweiligen Radio Network Subsystem RNS 
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und sog. Core-Network (CN) wird als EU-Interface bezeich- 
net. Das Core-Network ist dabei durch eine gestrichelte Um- 
rahmung in der Fig. 15 angedeutet. Der Informationspfad 
zwischen dem RNS und dem CN wird dabei insbesondere 
EU-Baerer genannt. Ein Radio-Bearer ist vorzugsweise der 
Service fur den Transfer von Nutzerdaten zwischen dem je- 
weiligen Teilnehmergerat UE und UTRAN (UMTS Terre- 
strial Radio Access Network). 

[0052] Insbesondere im UMTS-Funkkornrnunikationssy- 
stem sowie weiteren Funkkommunikationssystemen wie 
z.B. nach dem GPRS, EDGE, OFDM (Orthogonal Fre- 
quency Division Multiplexing) Prinzip sind Multicast-Ser- 
vices zur Verteilung von Multicast-Nachrichten von Inter- 
esse, 

[0053] Bisher werden lediglich im Internet Multicast- 
Dienste angeboten, d. h. auf der Festnetzseite. Ein solcher 
Dienst ist beispielsweise das EP Multicast. Das international 
gcnormtc Intcmct-Protokoll (IPV6) bictct die Moglichkeit 
der sog. Multicast-Adressierung. uber die Informationen 
zwischen Gruppen von Rechnern (oder ganzen Subnetzen) 
ausgetauscht werden konnen. Die Empfangergruppe, auch 
Multicast- Gruppe genannt, wird mit einer eindeutigen EP- 
Adresse (Multicast-Adresse) angesprochen, wobei der Sen- 
der die Zusammensetzung der Gruppe, z. B. Mitgliederan- 
zahl und Aufenlhaltsort nichl kennl. Einzelne Hosts, insbe- 
sondere Rechner konnen jederzeit einer Gruppe beitreten 
und sie wieder verlassen. Ein Host kann Mitglied in mehre- 
ren Gruppen sein. Um an eine Gruppe Daten zu senden. ist 
es nicht erforderlich, dass der Sender zwingend Gruppen- 
mitglied ist. Fur die Verwaltung von Mulucast-Gruppen und 
die Wegwahl (Routing) der Nachrichten zu den Teilnehmern 
einer IP Multicast- Gruppe gibt es im Internet unterschiedli- 
che Algorithmen bzw. Protokolle. 

Internet-Group-Managment-Protokoll (IGMP) 

[0054] Dieses Protokoll ermoglicht eine Multicast-Router 
(MC-Router) wie z. B. IPR von Fig. 16 Gruppenzugehorig- 
keiten einzelner Rechner wie z. B. HI mit HN abzufragen. 
Es gibt einem Host die Moglichkeit, auf solch eine Anfrage 
RQ alle seine Mitgliedschaften anzuzeigen. Das Internet- 
Group-Managment-Protokoll IGMP Version 1 kann zwei 
Arten von Meldungen versenden. Die eine nennt sich Host 
Membership Query (Typ = 1) und die andere Host Member- 
ship Report (Typ = 2). Ein Multicast-Router wie z. B. IPR 
von Fig. 16 informiert sich in seinem Zustandigkeitsbereich 
(Subnetz) iiber die anwesenden Gruppenmitglieder wie z. B. 
HI mit HN. Dies erreicht er durch die Aufforderung RQ an 
alle Hosts, ihre Gruppenzugehorigkeit bekannt zu geben 
(Host Membership Query). Solche Query s werden vorzugs- 
weise in periodischen Abstanden erzeugt, damit sich der 
Router IPR auf Veranderungen einstellen kann. Damit diese 
Nachricht alle Hosts erreicht, wird diese an die Gruppe aller 
Hosts im Subnetz gesendet. Nach Erhalt dieses Query s ant- 
wortet jeder Host fiir jede Gruppe, in der er Mitglied ist, mit 
einem Host Membership Report RE, was in der Fig. 17 ver- 
anschaulicht ist. Er gibt dem Multicast-Router EPR damit 
bekannt, dass er Mitglied dieser Gruppe ist. IGMP Version 2 
bietet Hosts die Moglichkeit, dem MC-Router beim Verlas- 
sen einer MC-Gruppe eine Leave-Nachricht zu zusenden, 
um so unnougen Verkehr zu vermeiden. Des weiteren kon- 
nen gruppenspezifische Querys versendet werden, was be- 
deutet, dass nicht immer alle Gruppenzugehorigkeiten abge- 
fragt werden, sondern vorzugsweise immer nur Bestimmte. 

Reverse Path Multicasting (RPM) 

[0055] Ein Algorithmus, der Multicast-Nachrichten vom 



Sender iiber ein Netz (z. B. Internet) bis zu den Empfangem 
verteilt, ist. das sog. Reverse Path Multicasting. Dessen 
Grundprinzip ist schematisch in der Fig. 18 veranschaulicht. 
Beim RPM-Verfahren wird ein erstes Datenpaket. (einer 
5 Multicast-Nachricht) eines Senders iiber das ganze Netz 
verteilt. Bekommtnun ein Blattrouter (Multicast Router, der 
keine weiteren Verbindungen zu anderen Routern hat) ein 
Paket einer Gruppe, fiir die er keine Mitglieder in seinem 
Subnetz hat (was er beispielsweise mit Hilfe von IGMP er- 
10 fragt hat), so sendet er an seine Vorganger eine sog. Prune 
Nachricht wie z. B. PRN. Damit teilt er seinem Vorganger 
mit, dass er zukiinftig Daten dieser Gruppe nicht mehr beno- 
tigt. Falls nun ein Router auf alien seinen child links (Ver- 
bindungen zu anderen Routern, auBer die, iiber die er die 
15 Nachricht bekommen hat) Prune Nachrichten erhalt und in 
seinem eigenen Subnetz auch keine Mitglieder fur diese 
Gruppe vorhanden sind, so gibt auch er an seine Vorganger 
cine Prune Nachricht fur diese Gruppe wcitcr. Somit bc- 
schrankt sich die Verteilung der Daten auf Pfade, die zu 
20 Gruppenmitgliedern fuhren. Bezogen auf Fig. 17 bedeutet 
dies, vorausgesetzt im Subnetz von Router E und F befinden 
sich keine Mitglieder der betrachtenden Gruppe, dass keine 
Daten vom Router B nach Router E gesendet werden, Um 
jedoch zu uberpriifen, ob in einem durch Prune Nachrichten 
25 verktirzten Teilbaum ein Host einer Gruppe beigeLreten ist, 
ist es zweckmaBig, in periodischen Abstanden Daten wieder 
iiber das ganze Netz zu senden. Jeder Router pro Gruppe 
speichert vorzugsweise Daten dariiber. an welchen Router er 
Pakete weitergeben darf und an welche nicht. 
30 [0056] Um nun fiir ein Funkkommunikationsnetz, insbe- 
sondere fur ein UMTS und/oder GPRS Mobilfunksystem, 
eine effiziente Verteilung von Multicast-Nachrichten zu er- 
moglichen, wird vom Grundkonzept her betrachtet zweck- 
mafiigerweise ein Eintrag der Mulucast-Gruppenzugehorig- 
35 keit in mindestens eine Datenbank, das Bekannunachen der 
Multicast-Gruppenteilnehmern in den Netz werkelemen ten 
des Funkkommunikationsnetzwerks (Multicast-Context ac- 
tivation) und/oder die Ubertragung einer Multicast-Nach- 
richt von der jeweiligen Nachrichtenqueile wie z. B. einem 
40 Multicast-Sender bis zur Nachricht ensenke wie z. B. dem 
End-Teilnehniergerat einer Multicast-Gruppe vorgenom- 
men. Im Rahmen der Erfindung wird haufig das sog. Multi- 
cast-Center erwahnt. Diese zusatzliche Komponente ist fiir 
das Generieren von Multicast-Nachrichten zustandig. 
45 [0057] Mit Hilfe dieser prinzipiellen Einfuhrung einer Da- 
tenbank fur den Eintrag der Multicast -Gruppenzugehorig- 
keiten sowie der Funktionalitatserweiterung der bereits be- 
stehenden Funknetzwerkkomponenten um die Fahigkeit, 
Multicast-Nachrichten erkennen zu konnen, ist eine einfa- 
50 che und effiziente Verteilung von Multicast-Nachrichten im 
jeweiligen Funkkommunikationssystem ermoglicht. Weiter- 
hin ist eine effiziente Anbindung an externe Festnetze er- 
moglicht, die insbesondere paketorientiert arbeiten. 
[0058] Fig. 1 zeigt in schematischer Darstellung die 
55 grundsatzliche Architektur eines UMTS-Funkkommunika- 
tionssy stems. Nicht gezeigt. ist dabei der Ubersichtlichkeit 
halber das sog. Home Location Register HLR als Daten- 
bank, die eine Verbindung zu SGSN und GGSN hat, wie 
dies in Fig. 15 dargestellt ist. Ebenfalls weggelassen ist das 
60 sog. Visitor Location Register VLR, das mit dem Home Lo- 
cation Register HLR verbunden ist. In einem solchen Funk- 
netzwerk FN1 entsprechend Fig. 1 bildet der GGSN den Zu- 
gang fur externe Netze EN zum UMTS-Funknetz. Am Gate- 
way GGSN sind ublicherweise mehrere ubergeordnete 
65 Funknctzwcrk-KontrolLcinhcitcn wie z. B. SGSN1 mit 
SGSGN3 iiber zugehorige Daten verbindungen LI1G mit 
LBG angekoppell. Diese Kontrolleinheiten SGSN1, 
SGSN2 sowie SGSN3 sind vorzugsweise fur den Verbin- 
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dungsaufbau im Funknetz FN1 verantwortlich. Jede hohere 
Funtoetzwerk- Kontrolleinheit wie z. B. SGSN1 mitSGSN3 
stent wiederum uber Datenverbindungen wie z. B. LI11, 
T-T21. T.T31, TJ202, 7.1503 mit untergeordneten Funknetz- 
werk-Kontrolleinheit RNC1, RNC2, RNC3, RNC20 sowie 
RNC50 in Wirkverbindung. Diese untergeordneten Funk- 
netz werkeinheiten werden im UMTS -Standard mit Radio 
Network Controller bezeichnet. Diese verwaiten jeweils die 
Ressourcen auf der Luftschnittstelle und stellen die Teilver- 
bindung zwischen dem jeweiligen RNC und dem End-Teil- 
nehmergerat her. Jedem Radio Network Controller sind ein 
oder mehrere Basis stationen zugeordnet, die uber jeweils 
mindestens eine Luftschnittstelle die Funkverbindung zu ein 
oder mehreren Teilnehmergeraten in ihrer jeweiligen Funk- 
zelle bereitstellen. 

[0059] Im Einzelnen ist an die erste hohere Funknetz- 
werk-Kontrolleinheit SGSN1 eine Gruppe von 3 unterge- 
ordneten Kontrollcinhcitcn, insbesonderc Radio Network 
Controller RNC1, RNC2, RNC3 uber entsprechende Daten- 
verbindungen 1211, 1221, 1231 angekoppelt. Die hohere 
Funknetzwerk-Kontrolleinheit SGSN2 steht in der Fig. 1 le- 
diglich mit der einzelnen untergeordneten Kontrolleinheit 
RNC20 uber die Datenleitung LI202 in Wirkverbindung. 
Mit der hoheren Netzwerkeinheit SGSN3 ist ebenfalls ledig- 
lich ein einzelner Radio Network Controller RNC50 uber 
eine Datenleitung LJ503 verbunden. An den ersten Radio 
Network Controller RNC1 sind in der Fig. 1 die beiden Ba- 
sisstationen BS11, BS12 uber zugehorige, separate Daten- 
verbindungen 12111*, LI121* angekoppelt. Im Bereich der 
Funkzellen dieser beiden Basisstationen BS11, BS12 halten 
sich dabei dabei die beiden Teilnehmergerat UE4 und UE5 
auf. Dem zweiten Radio Network Controller RNC2. der 
ebenfalls an derselben hoheren Funknetzwerk-Kontrollein- 
heit SGSN1 hangt, sind ebenfalls 2 Basisstationen BS21, 
BS22 uber entsprechende separate Datenverbindungen 
LI212*, LI222* zugeordnet. Im Funkzeilenbereich der Ba- 
sisstation BS22 befindet sich dabei im Ausfuhrungsbeispiel 
von Fig. 1 aktuell das Teilnehmergerat UE1. Der dritte Ra- 
dio Network Controller NNC3, der uber die Datenverbin- 
dung LI31 ebenfalls mit der hoheren Kontrolleinheit 
SGSN1 gekoppelt ist, versorgt schlieBlich die Basisstation 
BS31 uber eine Datenverbindung 12313*. In der Funkzelle 
dieser Basisstation BS31 halt sich beispielhaft das Teilneh- 
mergerat UE2 auf. 

[0060] Die 4 Teilnehmergerat UE1, UE2, UE4, UE5 sol- 
len nun als Multicast-Gruppe A vom extemen Netzwerk EN 
eine Multicast Nachricht moglichst effektiv empfangen kon- 
nen. Dazu wird den Komponenten des Mobilfunknetzes 
eine erweiterte Funktionalitat gegeben sowie zusatzlich 
mindestens ein sog. Multicast-Center eingefuhrt. Fig. 2 
zeigt ein derart gegenuber Fig. 1 modifiziertes Funknetz- 
werk FN2 insbesondere fur den UMTS- Standard. Das Mo- 
bilfunknetz FN2 weist als zusatzliches logisches Netzwerk- 
element gegenuber dem Funknetzwerk FN1 von Fig. 1 das 
Multicast-Center MCC auf. Es ist uber separate Datenver- 
bindungen wie z. B. LI1C, I22C, I23C mit alien hoheren 
Funknetzwerk- Kontrolleinheiten, hier im UMTS insbeson- 
dere Serving GPRS Support Nodes wie z. B. SGSN1, 
SGSN2, SGSN3 verbunden. Dabei konnen Nachrichten wie 
in einem IP-Festnetz iiblich, auch uber mehrere Netzwerk- 
knoten zu den einzelnen Serving GPRS Support Nodes ge- 
langen. Die Funktionalitat des Multicast-Centers umfasst 
dabei insbesondere die Verwaltung der fur das UMTS Mo- 
bilfunknetz zur Verfugung gestellte Multicast-Gruppen, 
d. h. allc zur Verfugung gcstctlten Multicast-Gruppen und 
deren Identitaten sind zur Adressierung im Multicast-Sender 
gespeichert und dort somit bekannt. Die Speicherung der 
Multicast-Gruppen ist in der Fig. 2 beispielhaft dadurch ver- 
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anschaulicht, dafi das Multicast-Center MCC iiber eine ge- 
strichelt gezeichnete Datenleitung K04 mit einer externen 
Speichervorrichtung SP1 verbunden ist. Ebenfalls der Ser- 
ving GPRS Support Node SGSN1 ist uber eine Datenver- 
bindung KOI mit der Speichervorrichtung SP1 verbunden 
und hat somit Zugriff auf deren Datenbestande. In dieser 
Speichervorrichtung SP1 ist unter einer gemeinsamen Iden- 
urizierungsadresse IDA die Multicast-Gruppe A abgeiegt, 
die im Ausfuhrungsbeispiel von Fig. 2 aktuell die Teilneh- 
mergerate UE1, UE2, UE4 und UE5 umfasst. In entspre- 
chender Weise dazu sind in der Speichervorrichtung SP1 
auch die Identifizierungsadressen wie z. B. IDB fur weitere 
Multicast-Gruppen abgespeichert. Mit dieser Speichervor- 
richtung SP1 sind vorzugs weise auch alle anderen hoheren 
Funknetzwerk-Kontrolleinheiten, insbesondere Serving 
GPRS Support Nodes verbunden. In der Fig. 2 ist im einzel- 
nen der Serving GPRS Support Node SGSN2 uber eine Da- 
tenverbindung K02, sowie der Support Node SGSN3 uber 
eine Datenverbindung K03 an die Speichervorrichtung SP1 
angekoppelt. Die Speichervorrichtung SP1 wird also vor- 
zugsweise als zentral gefuhrte Datenbank betrieben. Selbst- 
verstandlich kann es auch zweckmaBig sein, mehrere solche 
Speichervorrichtungen im Funknetz FN2 vorzusehen. Die 
Datenverwaltung der Multicast-Gruppen wird dabei eben- 
falls zweckmaSigerweise zenlralisiert als eine logische Ein- 
heit vorgenommen. 

[0061] Gegebenenfalls kann es auch zweckmaBig sein, 
solche Speichervorrichtungen zum Ablegen der Identifizie- 
rungsadressen fur die Multicast-Gruppen sowie deren spezi- 
fischen Teilnehmereintrage nicht als exteme, eigenstandige 
Komponenten im Netz zu installieren, sondern im Mulu- 
cast-Center selbst sowie in der jeweiligen hoheren Funk- 
netzwerk-Kontrolleinheit, insbesondere im jeweiligen Ser- 
ving GPRS Support Node zu integrieren (und nicht wie in 
Fig. 2 als separate Datenbank auszubilden). 
[0062] Neben der Verwaltung der Mulucast-Gruppen-Ein- 
trage fungiert das Multicast-Center MCC zusatzlich auch als 
Quelle fur alle Multicast-Nachrichten. 
[0063] Die Fig. 3 mit 5 stellen schematisch den zeitlichen 
Ablauf eines logischen Verbindungsaufbaus beispielhaft 
ausgehend vom extemen Netzwerk EN zum Teilnehmerge- 
rat UE4 dar. Es wird vorausgesetzt, dass sich das Teilneh- 
mergerat UE4 bereits im Funknetzwerk FN2 registriert hat, 
momentan jedoch keinen PDP Context (Paket Data Proto- 
koll) und keine aktive logische Ubertragungsverbindung 
zum Funknetz FN2 hat. Kommt nun ein Datenpaket PK4 fur 
das Teilnehmergerat UE4 vom extemen Paketdatennetz EN, 
so wird mit dem Datenpaket PK4 eine Identifikauon des 
Teilnehmergerats UE4 mitgeliefert. GGSN von Fig. 3 kennt 
nun entweder den SGSN an, an dem das Teilnehmergerat 
UE4 registriert ist, oder erfragt diese in der nicht eingezeich- 
neten Datenbank HLR. In diesem Ausfuhrungsbeispiel wird 
angenommen, das der GGSN weiB, dass das Teilnehmerge- 
rat UE4 am Support Node SGSN1 registriert ist. Daraufhin 
sender der GGSN dem SGSN1 eine Mitteilung MPK4, dass 
ein Datenpaket PK4 fur das Teilnehmergerat UE4 im GGSN 
angekommen ist. Der Support Node SGSN1 kennt im allge- 
meinen die sog. Routing Area, in der das Teilnehmergerat 
UE4 vermutet wird. Diese Routing- Area kann dabei meh- 
rere Radio Network Controller umfassen. Der Support Node 
SGSN1 sendet daraufhin eine Anfrage RQ1, RQ2, RQ3 an 
alle in Frage kommenden Radio Network Controller, hier 
RNC1, RNC2, RNC3, ob sich das Teilnehmergerat UE4 in 
den von den Radio Network Controllem verwalteten Funk- 
zellen befindet (= Paging Request). Die Radio Network 
Controller RNC1, RNC2, RNC3 senden daraufhin eine An- 
frage IF1, IF2, 3P3 in alle von ihnen verwaltete Funkzellen 
(= Paging). Das Teilnehmergerat UE4 meldet sich daraufhin 
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beim entsprechenden Radio Network Controller RNC1 . Der 
Radio Network Controller RNC1 teilt dann seiner iiberge- 
ordneten Kontrolleinheii SGSN1 mit, dass das Teilnehmer- 
gerat. UE4 sich in seinem Bereich befindet. Dies ist in der 
Fig. 4 durch das Antwortsignal RE1 angedeutet. Die uber- 
mittelten Signale sind dabei in den Fig. 3 mil 5 jeweils durcb 
dicker ausgezogene Pfeile veranschaulicht. Auf dieses Ant- 
wortsignal RE1 hin, baut nun der SGSN1 logische Ubertra- 
gungsverbindungen zum GGSN (core network bearer) und 
RNC1 (Iu-Baerer) auf, die nurDaten fur das Teilnehmerge- 
rat UE4 transportieren. Die logische Ubertragungsverbin- 
dung wird mit einem sog. PDP Context beschrieben, der alle 
notwendigen Daten der Verbindung zwischen dem Teilneh- 
mergerat und dem GGSN beinhaltet. Jeder logischen Uber- 
tragungsverbindung zwischen dem jeweiligen SGSN und 
GGSN ist dabei genau eine logische Ubertragungsverbin- 
dung zwischen SGSN und RNC zugewiesen, welcher wie- 
dcrum gcnau cine logische Ubertragungsverbindung zwi- 
schen RNC und dem Teilnehmergerat zugeordnet ist. Im 
SGSN und RNC bestehen somit feste Abbildungen der logi- 
schen Ubertragungsverbindungen, wodurch z. B. SGSN 
weiB, iiber welche logische Ubertragungsverbindung (und 
somit auch an welchen RNC) er eine Nachricht an das je- 
weilige Teilnehmergerat weiterleiten muss, wenn er die 
Nachricht iiber eine bestimmte logische Uberlragungsver- 
bindung von einem GGSN bekommt. In der Fig. 5 ist der 
komplette Ubertragungspfad vom GGSN zum SGSN1, wei- 
ter zum RNCL der Basisstation BS12 und schlieBhch zum 
End-Teilnehmergerat UE4 durch einen dicker ausgezogenen 
PfeilUPll angedeutet. 

[0064] Fig. 6 zeigt die Ubertragungsverbindungen mehre- 
rer Teilnehmergerate in einem Funkkommunikationssystem 
FN1 entsprechend Fig. 1. Jedes Teilnehmergerat hat fur jede 
ihm zugeordnete Ubertragungsverbindung einen PTP Con- 
text. Selbst wenn die Nachrichten, die aus dem extemen 
Netzwerk EN an die Teilnehmergerat UE1, UE2 und UE4, 
UE5 gesendet werden sollen, exakt gleich sind, ist es erfor- 
derlich, die Nachrichten an jeden Nutzer extra separat zu 
schicken, auch wenn die physikalischen Verbindungen die 
gleichen sind. Dies ist in der Praxis zu aufwendig und belegt 
zu viele Ressourcen. Denn zwischen alien Netzwerkkompo- 
nenten wird jeweils eine feste Abbildung von Nutzeridenti- 
fikationen auf logische Verbindungen durchgefuhrt, d. h. fur 
jeden einzelnen Teilnehmer wird eigens eine Verbindung 
aufgebaut. Fur die 4 Teilnehmergerate UE1, UE2, UE4, 
UE5 der MULTIC A STGRUPPE a werden somit im Ausfiih- 
rungsbeispiel von Fig. 6 insgesamt 4 komplette Obertra- 
gungspfade belegt, die vom extemen Netzwerk EN iiber den 
GGSN, SGSN1 so wie den zugeordnet en Radio Network 
Controllern RNC1, RNC2, RNC3 bis zu den Endteilneh- 
mergeraten durchgehend aufgebaut werden. 
[00651 Fig. 7 veranschaulicht, wie Multicast Nachrichten 
vom Multicast-Sender MCC zu den Teilnehmergeraten 
UE1, UE2, UE4, UE5 gesendet wurden, wenn man das Kon- 
zept nach Fig. 6 der festen Zuweisung von logischen Kana- 
len zu Teilnehmergeraten hier ebenfalls anwenden wtirde. 
Obwohl Multicast-Nachrichten, die von Multicast- Sender 
MCC gesendet werden, fur alle zu benachrichtigenden Teil- 
nehmergerate gleich sind. mussten sie dennoch fur jeden 
Nutzer einzeln zwischen Multicast- Sender MCC und 
SGSN1, SGSN1 und RNC1/RNC2/RNC3, und RNCs und 
den Endteilnehmergeraten UE1, UE2, UE4, UE5 gesendet 
werden. Dies bedeutet allgemein ausgedriickt, dass so viele 
Einzelverbindungspfade aufgebaut werden miissten, wie 
Endtcilnchmcrgcratc durch die Multicast Nachricht zu bc- 
nachrichtigen waren. Dies ware zu aufwendig und nicht aus- 
reichend efficient. 

[0066] Urn eine effizientere Verteilung von Gruppen nach- 



richten im Funkkommunikationsnetz FN2 von Fig. 2 zu er- 
moglichen, wird nach einer ersten Variante des erfindungs- 
gemaBen Verfahrens zweckmaBigerweise folgendermaBen 
entsprechend den Fig. 8 mit 10 vorgegangen: 
5 Das Multicast Center MCC sendet eine Multicast Nachricht 
GN1 fur die Multicastgruppe A an alle SGSNs (der Einfach- 
heit halber wird im weiteren nur SGSN1 betrachtet; entspre- 
chendes gilt fur die ubrigen SGSN's) 
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- SGSN1 hat nun erfindungsgemaB eine neue Funktio- 
nalitat und erkennt an Hand der mitgesendeten Multi- 
cast Gruppen Identitat, daB es sich bei der Nachricht 
um eine Multicast Nachricht handelt. 

- ErfindungsgemaB hat der SGSN1 die Muhicast 
Gruppenzugehorigkeiten aller bei ihm registrierten 
Nutzer gespeichen, Oder die Multicast Gruppenzuge- 
horigkeiten werden in der HLR Datenbank gespeichen 
und nun von SGSN dort crfragt. (sichc EM). 

- Es wird angenommen, daB Nutzer UE1, UE2 und 
UE4, UE5 zu der Multicast-Gruppe A gehoren. Weiter- 
hin wird angenommen, daB diese Nutzer keine aktive 
Verbindung habe. 

- SGSN1 kennt die Routing Areas in denen sich die 
Nutzer aufhalten konnten. Eine Routing Area kann 
mehrere RNCs uinfassen. 

- SGSN1 sendet nun entweder 1 Anfrage AF pro Nut- 
zer (hier also 4) an alle in Frage kommenden RNCs, ob 
der Nutzer sich in einer von diesen verwalteten RNCs 
befindet. Die Anfrage AF ist in der Fig. 8 durch dicker 
eingezeichnete Pfeile angedeutet. Wenn die Routing 
Areas gleich sind, kann erfindungsgemaB auch eine 
Anfrage mit einer Liste von Nutzern an die RNCs ge- 
sendet. werden. 

Die RNCs fragen wiederum in den von ihnen ver- 
walteten Funkzellen an, ob sich einer der zu benach- 
richtigenden Teilnehmergerate der Multicast-Gruppe A 
dort befindet. (Gemeinsame Anfrage fur mehrere Nut- 
zer ist moglich). 

- Die Nutzer melden sich bei den entsprechenden 
RNCs, welche wiederum die bei ihnen lokalisierten 
Nutzer zum SGSN1 melden, was in Fig. 9 durch dick 
eingezeichnete Pfeile RM angedeutet ist. 

- SGSN1 weiB nun, daB sich am RNC1 Nutzer UE4 
und UE5, am RNC2 Nutzer UE1 und an RNC3 Nutzer 
UE2 befindet . 

- ErfindungsgemaB wird nun zu jedem RNC, bei dem 
sich ein Nutzer dieser Multicast Gruppe befindet, ge- 
nau eine Ubertragungsverbindung aufgebaut. 

- Zu jedem Nutzer wird zwischen SGSN und Nutzer 
erfindungsgemaB ein Multicast Context aufgebaut, der, 
wie der PDP Context, die Verbindung beschreibt. 



[0067] Der Unterschied zum PDP Context liegt dabei 
darin, daB ein Multicast Context nicht fest einer Verbindung 
55 zugeordnet wird, sondem mehrere Multicast Contexte sich 
eine bzw. Teile der logischen Ubertragungsverbindung ge- 
meinsam nutzen. Ein Multicast Context ist jedoch ebenfalls 
nur genau einem Nutzer zugewiesen. 
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- Jeder SGSN wird dafur erweitert, daB er einer Uber- 
tragungsverbindung mehrere MC Contexte zuordnen 
kann. Dafur muB der SGSN auch die Liste der Nutzer 
Oder Mulucast Contexte speichem, die diesem Iu-Bea- 
rer zugeordnet sind. 

- Jcdcr RNC wird ebenfalls crweitert, um es zu cr- 
moglichen, die Daten nach dem RNC iiber einem Nut- 
zer zugeordnete Ubertragungsverbindungen weiterzu- 
leiten, d. h. also die Nachricht vervielfalugen und an 
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jeden Nutzer einzeln zu schicken. Dafur wird dern je- 
weiligen RNC beim Verbindungsaufbau des Iu-Bearers 
eine Liste der Identitaten der Nutzer oder Multicast 
Contexte mitgeliefert, die dem Tu-Bearer zugeordnet 
sind. Diese Liste wird im RNC gespeichert. 
- jeder RNC baut fiir jeden Nutzer, der sich in von ihm 
verwalteten Zellen befindet, eine Ubertragungsverbin- 
dung auf. 

[0068] Es besteht damit eine feste Abbildung einer Multi- 
cast Gruppe auf mehrere Iu-Bearer, jedoch maximal 1 (= ein 
einziger) Iu-Bearer pro RNC]. AuBerdem besteht eine feste 
Abbildung eines Iu-Bearers auf mehrere Radio Bearer. 
[0069] Fig. 11 veranschaulicht noch einmal den detaillier- 
ten Ablauf eines solchen Verbindungsaufbaus beispielhaft 
fiir das Teilnehmergerat UE4. Es wird davon ausgegangen, 
dass sich das Teilnehmergerat UE4 zunachst im Idle-Mode 
befindet, d. h. zwar cingcschaltct ist, abcr kcinc aktivc Vcr- 
bindung zum Funknetz FN2 aufweist. Kommt nun vom 
Multicast-Center MCC eine Multicast Nachricht MC-Mes- 
sage, so wird in der dem Support Node SGSN1 zugeordne- 
ten Speichervorrichtung die Multicast-Gruppe identifiziert 
an die die Multicast Nachricht gerichtet ist. Damit ist dem 
SGSN1 bekannt, welche Mitglieder dieser Multicast- 
Gruppe die Multicast Nachricht erhalten sollen. Der SGSN1 
initiiert daraufhin ein Paging fur die jeweilig zu benachrich- 
tigenden Teilnehmergerate dieser Gruppe. Dazu wird an alle 
an den SGN1 angekoppelten RNCs ein Anfragesignal ge- 
sendet, ob sich in ihren Funkzellenbereicnen die Teilneh- 
mergerat UE1, UE2, UE4, UE5 aufhalten. Die Radio Net- 
work Controller senden diese Paging- Signale iiber ihre zu- 
gehorigen Basisstationen in ihre zu versorgenden Funkzel- 
lenbereiche aus. Befindet sich eines der zu benachrichtigen- 
den Teilnehmergerate im Versorgungsbereich dieser Radio 
Network Controller, so schalten diese Teilnehmergerate 
vom Idle-Mode auf dem Connected-Mode urn. d. h. es wird 
eine aktive Verbindung RRC- Connection Meldung (Radio 
Resource Control) zuriick an den jeweiligen Radio Network 
Controller geschickt. Derjenige Radio Network Controller - 
hier RNC1 der von seiner jeweiligen Basisstation gemel- 
det bekommt, dass sich in deren Funkzelle ein zu benach- 
richtigendes Teilnehmergerat aufhalt, macht dies auch der 
iibergeordneten Kontrolleinheit ~ hier SGSN1 - bekannt. 
Diese fordert dann entsprechend dem Ablaufpunkt 6 von 
Fig. 11 vom jeweiligen Teilnehmergerat wie tl B. UE4 den 
Multicast-Context an, urn eine Wegbeschreibung zum End- 
teilnehmergerat. entsprechend Punkt 7 zuruckzuerhalten. In 
der unteren Bildhalfte von Fig. 11 ist unterhalb der gestri- 
chelten Linie der Zustand dargestellt, ab oder bei dem sich 
die Teilnehmergerate UE4 und UE5 bereits im Connected- 
Mode befinden. Dies entspricht dem Endzu stand nach der 
Signalisierung des Ablaufpunktes 7. "Aktivate Multicast- 
Context -Request". Da nun die ubergeordnete Kontrollein- 
heit SGSN1 weiB, welche Radio Network Controller zustan- 
dig sind fur die zu benachrichtigenden Teilnehmergerate, 
und ein entsprechender Multicast-Context zum Verbin- 
dungsaufbau zum jeweiligen Teilnehmergerat zur Verfu- 
gung stent, wird nun vom SuppordNode SGSN1 ein Verbin- 
dungsaufbau zu den zu benachrichtigenden Teilnehmergera- 
ten - hier UE4 - initiiert. Dazu wird entsprechend Ablauf- 
punkt 8 ein Iu-Baerer zwischen dem RNC1 und dem SGSN1 
aufgebaut. Zusatzlich wird die Information mitgegeben, 
dass der Iu-Baerer fiir den Teilnehnter UE4 und UE5 be- 
steht. Daraufhin wird zwischen dem RNC1 und den Endteil- 
nehmergeraten UE4 und UE5 jewcils ein Radio-Bacrcr ent- 
sprechend dem Ablaufpunkt 9 aufgebaut und dies entspre- 
chend dem Ablaufpunkt 10 dem Radio Network Controller 
RNC1 bestatigt. Damit konnten Radio-Baerer zu alien End- 



teilnehmergeraten - hier UE4, UE5 - die am Radio Net- 
work Controller RNC 1 angekoppelt sind, aufgebaut werden. 
Gleichzeitig wird die Abbildung von einem einzelnen Iu- 
Baerer zwischen dem Radio Network Controller RNC1 und 
5 der iibergeordneten Kontrolleinheit SGSN1 auf mehrere Ra- 
dio-Baerer zwischen Radio Network Controller RNC1 und 
den Endteilnehmergeraten UE4, UE5 im Radio Network 
Controller RNC1 gespeichert. Dieser bestatigt den Aufbau 
des Iu-Baerers nach Ablaufpunkt 11. Daraufhin sendet der 
10 Support Node SGSN1 ein Bestatigungssignal Aktivate Mul- 
ticast Context Exept nach Ablaufpunkt 12 an den jeweiligen 
Endteilnehmer IJE4 bzw. IJE5. SchlieBlich wird iiber den 
aufgebauten Ubertragungspfad die Multicast Nachricht vom 
SGSN1 an die Endteilnehmergerate UE4, UE5 ubertragen. 
15 [0070] Bei dem Ubertragungskonzept entsprechend den 
Fig. 10 und 11 wird also zusarnmenfassend betrachtet zu- 
nachst die Multicast Nachricht fur die Multicast-Gruppe A 
an den Support Node SGSN1 ubertragen. Der Support Node 
SGSN1 kennt aufgrund seiner Speicherzugriffsmoglichkeit 
20 diejenigen Radio Network Controller und die logischen 
Ubertragungsverbindung (Iu-Bearer), die fiir Nachrichten 
der Multicast-Gruppe A aufgebaut wurden, und sendet die 
Multicast Nachricht nur einmal zu jedem der Radio Net- 
work Controller, mit denen ein Nutzer dieser Multicast- 
25 Gruppe verbunden ist. Der jeweilige Radio Network Con- 
troller kennt die Nutzer der Multicast-Gruppe A und die lo- 
gischen Ubertragungsverbindungen zu den Nutzern (Radio 
Baerer), die mit dem Iu-Baerer also der am RNC ankom- 
menden Verbindung verknupft sind. Der jeweilige Radio 
30 Network Controller sendet nun die Multicast Nachricht der 
Multicast-Gruppe A iiber die aufgebauten Verbindungen 
(Radio Baerer) fur jeden Nutzer einmal. Obwohl also hier 
im Ausfiihrungsbei spiel von Fig. 10 vom Radio Network 
Controller RNC 1 mehrere Teilnehmergerate UE4, UE5 ver- 
35 sorgt werden, wird lediglich ein einzelner Ubertragungspfad 
zwischen dem Radio Network Controller RNC1 und dem 
iibergeordneten Support Node SGSN1 aufgebaut und be- 
nutzt. Dies ermoglicht eine effiziente Verteilung der Multi- 
cast Nachricht GN1. 
40 [0071] Fig. 12 zeigt eine weitere Variante zur erfindungs- 
gemafien Verteilung von Multicast Nachrichten zwischen 
dem Multicast-Sender MCC und den zu benachrichtigenden 
Endteilnehmergeraten einer bestimmten Multicast-Gruppe 
wie z. B. A. Vom Support Node SGSN1 wurde wie in Fig. 
45 10 zum RNC1 ebenfalls eine logische Ubertragungsverbin- 
dung (Iu-Baerer) pro Nutzer aufgebaut. Des Multicast-Cen- 
ter MCC sendet dabei die Multicast Nachricht GN1 vor- 
zugsweise nur einmal. Der Support Node SGSN1 kennt er- 
findungsgemaB die Teilnehmergerate dieser Multicast- 
50 Gruppe A aufgrund seiner Zu griff smoglichkeit in die Spei- 
chervorrichtung SP1 von Fig. 2 und damit die zugehorigen 
logischen Ubertragungsverbindungen zu den Radio Net- 
work Controllern. Der Support Node SGSN1 vervielfaltigt 
die eingehende Multicast Nachricht GN1 und sendet diese 
55 Nachricht jeweiis einmal pro Teilnehmergerat an die ent- 
sprechenden Radio Network Controller RNC1, RNC2, 
RNC3. Da am Radio Network Controller RNC1 hier im 
Ausfuhrungsbeispiel 2, d. h. allgemein ausgedriickt mehrere 
Teilnehmer hangen, werden entsprechen viele logische 
60 Ubertragungsverbindungen zu Ubermittlung der Grupppen- 
nachricht GN1 bereitgestellt zwischen den Support Node 
SGSN1 und dem Radio Network Controller RNC1. Im Ein- 
zelnen heiBt das, dass ein Ubertragungspfad UP11* zwi- 
schen den Support Node SGSN1 und dem Radio Network 
65 Controller RNC1 fiir das Teilnehmergerat UE4 sowic cin 
weiterer, zweiter Ubertragungspfad UP1 1 ** fiir das Teilneh- 
mergerat UE5 abgestellt. wird. Vorteilhaft bei dieser Uber- 
tragungsvariante ist insbesondere: Es ist keine neue Funk- 
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tionalitai ira jeweiligen Radio Network Controller erforder- 
lich. Die ubergeordente Funknetzwerk-Kontrolleinheit 
SGSN1 kann weiterhin ahnlich dem PDP Context eine Ver- 
bindung pro Nutter aufbauen. Fur die ubergeordnete Funk- 
netzwerk-Kontrolleinheit SGSN1 und dem jeweitigen Ra- 5 
dio Network Controller ist es nicht erforderlich, eine Liste 
der Multicast-Context bzw. Teilnehmergerate der jeweilig 
zu benachrichtigenden Multicast-Gruppe zu fiihren, die zu 
einer logischen Ubertragungsverbindung gehoren. Auf diese 
Weise ist eine Umanderung der Signalisierung zwischen den 10 
Netzwerkkomponenten bestehender Mobilfunknetze weit- 
gehend vermieden. Lediglich die Einfuhrung eines Multi- 
cast-Senders sowie einer zentral gefuhrten Datenbank fiir 
die Multicast-Gruppen ist zur Durchfuhrung des erfindungs- 
gemaBen Verfahrens zweckmaBig. 15 
[0072] Fig. 13 zeigt diesen Verbindungsaufbau passend zu 
Fig. 12 nochmals im Detail Anderungen gegeniiber dem 
Vcrfahrcn von Fig. 1 1 sind jcwcils grau untcrlcgt gczcich- 
net. 

[0073] Fig. 14 zeigt schlieBlich einen Registrierungspro- 20 
zess beispieihaft fur Teilnehmergerat UE4. Schaltet das 
Teiinehmergerat UE4 sein Mobilfunkgerat an, wird zu- 
nachst eine Radio Resource Control! Verbindung zum Radio 
Network Controller RNC1 aufgebaut. AnschlieBend authen- 
tifiziert sich das Teilnehinergeral UE4 am Support Node 25 
SGSN1 . Dabei wird bei der Authentifizierung die Multicast- 
Gruppenzugehorigkeit des Teilnehmergerats UE4 zum Sup- 
port Node SGSN1 iibertragen. Der Support Node SGSN1 
speichert diese Informauonen in einer intemen oder exter- 
nen Datenbank. Altemativ konnen die Informauonen auch 30 
an eine externe Datenbank wie z. B. einem erweiterten 
Home Location Register HLR weitergeleitet werden. Dafur 
wird eine Identifikation des Teilnehmergerats UE4 sowie 
Identifikationen der Multicast-Gruppen dieses Teilnehmer- 
gerats an eine solche Datenbank gesendet. 35 
[0074] Zusammenfassend betrachtet sind somit folgende 
Schritte zum effizienten Verteilen von Multicast Nachrich- 
ten in einem Funkkommunikationssystem vorteilhaft: 

1. Einfuhrung eines logischen Netzwerkelementes 40 
"Multicast Center*': 

Das Multicast Center hat die Aufgabe, die Multicast 
Gruppen zu verwalten, die Informationen fur die Mul- 
ticast Gruppen bereitzustellen und sie an alle SGSNs 
im UMTS Netzwerk zu senden. Dazu speichert es 45 
zweckmaBigerweise auch eine Identitat einer Multicast 
Gruppe, die im gesamten Netzwerk eindeutig ist. 

2. Erweiterung der SGSN Funktionalitat um die Fa- 
higkeit zu erkennen, daB es sich bei einer empfangenen 
Nachricht um eine Multicast Nachricht handelt. 50 

3. Erweiterung des SGSN um die Fahigkeit, Multicast 
Gruppenzugehorigkeiten der an dem SGSN registrier- 
ten Nutzer zu speichem. 

4. Alternativ zu 3. kann die Gruppenzugehorigkeitsin- 
formation auch in einer extemen Datenbank (z. B. 55 
HLR) gespeichert werden. Dazu wird die HLR Funk- 
tionalitat zweckmaBigerweise erweitert. AuBerdem 
wird der SGSN zweckmaBigerweise die zusatzliche 
Fahigkeit gegeben, die Gruppenzugehorigkeiten bei 
der extemen Datenbank zu erfragen. 60 

5. Erweiterung der SGSN Funktionalitat durch die Fa- 
higkeit, Daten zu speichem, die eine fur einen nutzer- 
spezifische Verbindung zum SGSN beschreiben. Diese 
Daten werden im weiteren Multicast Contexte genannt. 

6. ErfindungsgcmaB gchorcn zum Mulucast Context 65 
mindestens eine Idenufikation des Nutzers und eine 
Identifikation der Multicast Gruppe. 

7. Erweiterung der SGSN Funktionalitat durch die Fa- 
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higkeiL, eine logische Ubertragungsverbindung fur 
mehrere Multicast Contexte zwischen SGSN und RNC 
aufzubauen, die zur selben Multicast Gruppe gehoren 
und die Liste der Multicast Contexte dieser Ubertra- 
gungsverbindung zu speichem und zu aktualisieren 
(wenn z. B. ein Nutzer den RNC wechselt). 

8. Erweiterung der RNC Funktionalitat durch die Fa- 
higkeit, eine Liste der Multicast Contexte bzw. Nutzer 
zu speichem und zu aktualisieren, die zu einer logi- 
schen Verbindung zwischen RNC und SGSN gehoren. 

9. Erweiterung der RNC Funktionalitat durch die Fa- 
higkeit eine logische tJbertragungsverbindung zwi- 
schen RNC und SGSN (Iu-Bearer) auf mehrere logi- 
sche Ubertragungsverbindungen zwischen RNC und 
Nutzer bzw. UE (Radio Bearer) abzubilden. 

10. Hinzufugen der Multicast-Gruppenzugehorigkeit 
eines Nutzers in die Registrierungsnachricht, damit 
dicsc im SGSN gespeichert werden kann, bzw. vom 
SGSN an eine exteme Datenbank (z. B.) HLR weiter- 
geleitet werden kann, wo sie dann gespeichert wird. 

[0075] Im Weiteren wird auf die Einfuhrung der effizien- 
ten Verteilung von Multicast Nachricht insbesondere im 
Hinblick auf UNTS eingegangen: 

1 . Eintrag der MC-Gruppenzugehorigkeit in eine Datenbank 

[0076] Das im Internet verwendete Protokoll IGMP zur 
Erfassung der Teilnehmer von Multicast-Gruppen ist fiir 
UMTS nicht gut geeignet. Durch das "Nachfragen" (Query, 
Report.) nach der Multicast-Gruppenzugehorigkeit bei alien 
Hosts, somit also auch bei solchen, die keine Teilnehmer der 
entsprechenden Multicast-Gruppe enthalten, komnit es zu 
zusatzlicher Ubertragungs-Komplexitar und somit erhohtem 
Bandbreitebedarf. 

[0077] Im Rahmen dieser Erfindung soil der Eintrag der 
Zugehorigkeit von Teilnehmem zu Mulucast- Gruppen in 
eine zentrale Datenbank vorgenommen werden (Fig. 19). 
Im UMTS-Corenetwork kann dafur moglicherweise das 
HLR, HSS (home subscriber server), VLR, der SGSN oder 
der GGSN verwendet werden. 

[0078] Teilnehmer, die zu einer bestimmten Multicast- 
Gruppe beitreten oder diese verlassen wollen, senden eine 
Nachricht, eventuell iiber verschiedene Netzwerkknoten, 
entweder direkt an die Datenbank oder an einen Netzwerk- 
knoten. der wiederum den Eintrag in die Datenbank vor- 
nimmt. Der Netzwerkknoten, der die Eintragung in die Da- 
tenbank vornehmen soli, kann beispielsweise der SGSN 
sein. 

[0079] Kommt es nun zur Ubertragung einer Multicast- 
Nachricht, erfolgt zuerst eine Anfrage an diese Datenbank, 
ob und welche Teilnehmer der entsprechenden Multicast- 
Gruppe angehoren. 

[0080] Der Vorteil dieses Verfahrens ist, dass die Zugeho- 
rigkeit von Teilnehmem zu Multicast-Gruppen aus einer 
zentralen Datenbank erfragt werden kann. 
[0081] Zusatzliche Ubertragungskomplexitat und der so 
entstehende zusatzliche Bandbreitebedarf wie fur das IGMP, 
wie es beispielsweise im Internet praktiziert wird, wird so 
vermieden. 

[0082] Der Eintrag in die Datenbank kann ggf. auch ge- 
trennt vom UMTS-Netzwerk beispielsweise durch den 
Netzbetreiber durchgefuhrt werden. 

Ausfuhrungsbcispicl 

[0083] Fur das Ausfuhrungsbeispiel wird angenommen, 
dass sich Teilnehmer X bei einer Multicast-Gruppe anmel- 
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den will. Mit Hilfe einer entsprechenden Application gene- 
riert er eine Registrierungs-Anforderung (Subscriber-Nach- 
richt), welche mind, seine Identitat (IMSI, IP-Adresse o. a.) 
und die MC-Adresse der entsprechende Multicast-Gruppe 
enthalt. Diese Subscriber-Nachricht sender er nun iiber den 
RNC zum SGSN (Serving GPRS Support Node). 
[0084] Der SGSN erkennt, dass es sich um eine Registrie- 
rungs-Anforderung handelt und veranlasst einen Eintrag in 
die zentrale Datenbank. 

[0085] Die Adressen der Teilnehmer der entsprechenden 
MC-Gruppen konnen fur den Transport der MC-Nachrich- 
ten zu den Teilnehmern aus der Datenbank abgefragt wer- 
den. Dort erfolgt ein Mapping von Teilnehmer auf Multi- 
cast-Gruppe bzw. Mulitcast-Gruppe auf Teilnehmer. Mit 
Hilfe dieser Information aus der Datenbank in Kombination 
mit der Location Information aus dem SGSN, welcher RNC 
den MC-Teilnehmer bedient, konnen nun die MC-Nachrich- 
tcn zu den entsprechenden SRNC und daraufhin zu den MC- 
Teilnehmem ubertragen werden. 

2. MC-Context activation 

[0086] Nach dem Einschalten eines UE wird als erstes 
eine Registrierungs- und Authentifizierungsprozedur einge- 
leitet. Dafur gent das UE zuersl in den Connected Mode 
uber. Uber den Aufbau einer RRC-Connection zum RNC 
und einer Signalisierung zum SGSN macht sich das UE 
beim SGSN bekannt. 

[0087] Dem SGSN ist nun unter anderem die Identitat des 
UE und des RNC bekannt, der das entsprechende UE ver- 
sorgt. 

[0088] Kommt es zu keinen weiteren Aktionen des UE 
(Gesprachsaufbau, Daten ubertragung etc.) so fallt es in den 
Idle-Mode. Samtliche Verbindungen werden abgebaut und 
der SGSN hat lediglich Information iiber die Identitat des 
UE und die Routing- Area in der es sich befindet. 
[0089] Das hier vorgestellte Verfahren, bezeichnet als 
"Multicast-Context activation", beschreibt den Prozessab- 
lauf, wie sich ein UE mit seinen MC-Gruppenzugehorigkei- 
ten beim SGSN bekannt macht. 

[0090] Nach dieser Prozedur sind dem SGSN wie bisher 
die Identitat und die Location Information, zusatzlich nun 
aber auch die MC-Gruppenzugehorigkeiten des UE be- 
kannt. 

[0091] Eine Moglichkeit zur Aktivierung eines MC-Con- 
textes ist, dass ein UE beim Einschalten und der darauf fol- 
genden Registrierungs- und Authenufizierungsprozedur je- 
des Mai standardmaBig (default) seine MC-Gruppenzuge- 
horigkeit zum SGSN mit uber tragi (Fig. 20). Diese Infor- 
mationen werden im SGSN gespeichert und bilden den MC- 
Context. 

[00921 Fallt das UE daraufhin in den Idle-Mode (im Falle 
keiner weiteren Aktionen des UE), so muss der SGSN neben 
den Inforxnationen iiber die Identitat und die Routing-Area 
des UE nun auch die MC-Gruppenzugeh6rigkeit5-Informa- 
tionen speichern. 

[0093] Denkbar ist auch der Fall, dass die MC-Gruppen- 
zugehorigkeits -Information nach dem Einschalten eines UE 
und der darauf folgenden Registrierungs- und Authentifizie- 
rungsprozedur standardmaBig (default) vom SGSN aus ei- 
ner Datenbank (siehe Eintrag der MC-Gruppenzugehorig- 
keit in eine Datenbank) abgefragt wird (Fig. 21). Diese In- 
formationen werden im SGSN gespeichert und bilden den 
MC-Context. 

[0094] Fallt das UE daraufhin in den Idle-Mode (im Fallc 
keiner weiteren Aktionen des UE), so speichert der SGSN 
neben den Informationen iiber die Identitat und die Routing- 
Area des UE nun auch die MC-Gruppenzugehorigkeits-In- 



formationen. 

[0095] Eine weitere Moglichkeit ist, dass die MC-Grup- 
penzugehorigkeits-Information beim Eintreffen einer MC- 
Message bzw. eines MC-Message-Request vom SGSN aus 

5 einer Datenbank (siehe Eintrag der MC-Gruppenzugehorig- 
keit in eine Datenbank) abgefragt wird (Fig. 22). Diese In- 
formationen werden im SGSN gespeichert und bilden den 
MC-Context. Vorteii dieser Variante ist, dass die MC-Grup- 
penzugehorigkeits-Information nicht standig im SGSN ge- 

10 speichert werden muss, sondern nur dann, wenn MC-Nach- 
richten eintreffen bzw. iibertragen werden. 
[0096] Damit die MOCjruppenzugehorigkeits-Informa- 
tion aber nicht bei jeder einzelnen MC-Nachricht einer be- 
stimmten Gruppe oder sogar bei jedem einzelnen IF-Packet 

15 einer MC-Nachricht neu abgefragt werden muss, kann ein 
Timer initialisiert werden. 

[0097] Kommt es nun zu einer erneuten Ubertragung einer 
MC-Nachricht, bevor der Timer abgclaufcn ist, so muB die 
MC-Gruppenzugehorigkeits-Information nicht erneut abge- 
20 fragt werden, da die Informationen wahrend der Laufzeit 
des Timers gespeichert wird. 

[0098] Grundsatzlich kommt es zu einem Update der MC- 
Gruppenzugehorigkeits-Information im SGSN, wenn sich 
neue Mitgtieder zu einer MC-Gruppe anmelden bzw. diese 
25 verlassen (siehe dazu Abschnill 1. Einurag der MC-Grup- 
penzugehorigkeit in eine Datenbank). 

3. Aufbau der Verbindungswege und Ubertragung der MC- 
Nachrichten 
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I. Ausfuhrungsbeispiel 



[0099] Fiir dieses Beispiel wird angenommen, dass eine 
MC-Nachricht im IP-MC-Center (MCC) generiert wurde 

35 und nun zu den Teilnehmern dieser MC-Gruppe gesendet 
werden soli. Diese MC-Nachricht ist mit der MC-Adresse 
der entsprechenden MC-Gruppe adressiert. Das IP-Multi- 
cast-Center hat die Funktionalitat eines IP-MC-Routers. 
[0100] Die MC-Nachricht wird nun zu alien SGSNs ge- 

40 sendet (1. in Fig. 23). Aufgrund der Aktivierung des MC- 
Kontextes (siehe Abschnitt 2. MC-Context activation) sind 
dem SGSN die UEs und ihre MC-Gruppenzugehorigkeiten 
bekannt. Das SGSN kennt die UE5, die die MC-Nachricht 
erhalten sollen und deren Routing Areas (RA), in denen sich 

45 die UEs befinden. 

[0101] Befindet sich ein UE, das Mitglied der entspre- 
chenden MC-Gruppe ist, im Idle-Mode, so wird nun vom 
SGSN ein MC-Message-Request an alle RNCs in der ihm 
bekannten Routing Area gesendet (2. in Fig. 23). Dieser 

50 MC-Msg. -Request beinhaltet die Identitat der UEs (z. B. 
IMSI. IP-Adresse o. a.) und die MC-Adresse der entspre- 
chenden MC-Gruppe. 

[0102] Die RNCs fuhren daraufhin ein Paging der UEs 
durch, die im MC-Msg. -Request benannt sind (3. in Fig. 
55 23). 

[0103] Diese UEs bauen nun eine RRC-Connection und 
Radio Bearer (RB) zum RNC auf und befinden sich darauf- 
hin im Connected Mode (4. in Fig. 23). 
[0104] Befindet sich ein UE, das Mitgtied der entspre- 

60 chenden MC-Gruppe ist, bereits im Connected-Mode, so 
wird ein MC-Msg .-Request von SGSN iiber die RNCs zu 
den entsprechenden UEs, welche Mitglieder der MC- 
Gruppe sind, gesendet (5. in Fig. 23). Dieser MC-Msg.-Re- 
quest beinhaltet die Identitat der UEs (z. B. IMSI. TP- 

65 Adrcssc o. a.) und die MC-Adrcssc der entsprechenden MC- 
Gruppe. 

[0105] Da sich die UEs bereits im Connected Mode befin- 
den (RRC Connection besteht), miissen nun (soweit noch 
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nicht vorhanden) Radio Bearer (RB) zum RNC aufgebaut 
werden (6. in Fig. 23). 

[0106] Nachdem sich nun alle UEs der MC-Gruppe im 
Connected Mode hefinden und sowohl eine RRC-Connec- 
tion als auch Radio Bearer aufgebaut sind, wird nun von je- 
dem RNC, der Mitglieder der MC-Gruppe versorgt, zum 
SGSN ein MC-Bearer pro RNC aufgebaut (7. in Fig. 23). 
Ein MC-Msg. -Con firm., der vom RNC iiber diese MC-Bea- 
rer gesendet wird, gibt nun dem SGSN die Bereitschaft der 
UEs kund, MC-Nachrichten empfangen zu konnen. Der 
SGSN hat nun die Informationen, wo sich die UEs der MC- 
Gruppe befinden und kann nun die MC-Nachricht uber die 
zuvor aufgebauten MC-Bearer zu dem enlsprechenden 
RNCs senden (8. in Fig. 23). 

[0107] Mit der Mapping-Information (UE/MC-Gruppe) 
aus dem MC-Msg. -Request kann die MC-Nachricht nun zu 
den UEs der MC-Gruppe ubertragen werden (9. in Fig. 23). 
[0108] Ein SGSN, der cine MC-Nachricht fur cine bc- 
stimmte MC-Gruppe bekommt aber keine Mitgheder dieser 
MC-Gruppe versorgt, benotigt diese Nachricht. nicht und 
kann sie verwerfen. 

[0109] Eine weitere Moglichkeit ist, dass der SGSN, so- 
fern er keine Mitglieder der MC-Gruppe besitzU eine Prune- 
Nachricht (Vergl. RPM) an das IP-Mulucast-Center zuriick 
sendet. Dieser SGSN erhall dann solange keine MC-Nach- 
richten fur die MC-Gruppe, bis: 

- der SGSN an das IP-MC-Center eine Join-Nachricht 
sendet, die den Eintritt eines Teilnehmers in eine MC- 
Gruppe signalisiert (event-triggered). 

- ein zuvor festgelegter Timer abgelaufen ist. 

[0U0] Denkbar ist auch der Fall, dass die MC-Nachricht, 
nachdem sie im MCC generiert wurde, nicht sofort an alle 
SGSNs gesendet wird (Vergl. 1. in Fig. 23). Stattdessen 
kann auch zuerst ein MC-Message-Request zu den SGSNs 
gesendet werden (1. in Fig. 24). 

[0111] Die weiteren Prozeduren zum Aufbau der Verbin- 
dungen fur die Ubertragung der MC-Nachricht vom SGSN 
zu den UEs der MC-Gruppe-Teilnehmer bleiben dann gleich 
(2. bis 7. in Fig. 24). 

[0112] Nachdem dann der MC-Msg.-Req. beim SGSN 

eingegangen ist (7. in Fig. 24), wird nun ein Bearer (pro 

SGSN) vom SGSN zum MCC aufgebaut und es erfolgt ein 

MC-Msg.-Req. an das MCC (8. in Fig. 24). 

[0113] Erst jetzt sendet das MCC die MC-Nachricht an 

alle SGSNs zu denen Bearer aufgebaut sind und von denen 

er die MC-Msg.-Req. erhalten hat (9. in Fig. 24). 

[0114] Die weiteren Schritte (10. und 11. in Fig. 24) sind 

nun wieder identisch mit 8. und 9. aus Fig. 23. 

[0115] Eine weitere Moglichkeit ist, dass nach dem Ein- 

treffen des MC-Msg.-Req. beim SGSN (7. in Fig. 25) nun 

ein Bearer pro RNC vom SGSN zum MCC aufgebaut wird 

(8. in Fig. 25). Uber diese RNC-spezifischen Bearer werden 

nun die MC-Nachrichten uber den SGSN zu den entspre- 

chenden RNCs weitergeleitet (9. in Fig. 25). 

[0116] Mit der Mapping-Informauon (UE/MC-Gruppe) 

aus dem MC-Msg. -Request kann die MC-Nachricht nun zu 

den UEs der MC-Gruppe ubertragen werden (10. in Fig. 

25). 

[0117] Damit die Verbindungswege (Bearer) fur die Uber- 
tragung der MC-Nachrichten zu den einzelnen UEs einer 
MC-Gruppe nicht fur jede einzelne MC-Nachricht einer be- 
stimmten Gruppe oder sogar bei jedem einzelnen IP-Packet 
cincr MC-Nachricht ncu aufgebaut werden musscn, kann 
ein Timer initialisiert werden. Die Verbindungen (Bearer) 
werden nun solange aufrecht erhalten, bis der Timer abge- 
laufen ist. Kommt es zu einer erneuten Ubertragung einer 



MC-Nachricht, bevor der Timer abgelaufen ist, so wird die 
MC-Nachricht iiber die noch bestehenden Verbindungswege 
ubertragen. 

[0118] Eine weitere Moglichkeit ist der Abbau der Bearer 
5 durch explizite Signalisierung ausgehend vom MCC, SGSN 
oder beiden. 

II. Ausfuhrungsbeispiel 

10 [0119] Fur dieses Beispiel wird emeut angenommen, dass 
eine MC-Nachricht im IP-MC-Center generiert wurde und 
nun zu den Teilnehmern dieser MC-Gruppe gesendet wer- 
den soli. Diese MC-Nachricht ist mit der MC-Adresse der 
entsprechenden MC-Gruppe adressiert. Das IP-Multicast- 

15 Center hat die Funktionalitat eines IP-MC-Routers. 

[0120] Die Schritte 1. bis 6. sind jeweils identisch mit de- 
nen aus Verfahren I. 

[0121] Nachdem sich nun alle UEs der MC-Gruppc im 
Connected Mode befinden und sowohl eine RRC-Connec- 

20 uon als auch Radio Bearer aufgebaut sind, wird nun von je- 
dem RNC, der Mitglieder der MC-Gruppe versorgt, zum 
SGSN ein Iu-Bearer pro UE aufgebaut (7. in Fig. 26). Ein 
MC-Msg.-Confirm. ? der vom RNC uber diese Iu-Bearer ge- 
sendet wird, gibt nun dem SGSN die Bereitschaft der UEs 

25 kund, MC-Nachrichlen empfangen zu konnen. Der SGSN 
hat nun die Informationen, wo sich die UEs der MC-Gruppe 
befinden und kann nun die MC-Nachricht iiber die zuvor 
aufgebauten Iu-Bearer zu dem entsprechenden UE senden 
(8. in Fig. 26). 

30 [0122] Ein SGSN, der eine MC-Nachricht fur eine be- 
stimmte MC-Gruppe bekomrnL, aber keine Mitglieder dieser 
MC-Gruppe versorgt, benotigt diese Nachricht nicht und 
kann sie verwerfen. 

[0123] Eine weitere Moglichkeit ist, dass der SGSN, so- 
35 fern er keine Mitglieder der MC-Gruppe besitzt, eine Prune- 
Nachricht (Vergl. RPM) an das IP- Multicast-Center zuruck- 
sendet. Dieser SGSN erhalt dann solange keine MC-Nach- 
richten fur die MC-Gruppe, bis: 

40 - der SGSN an das IP-MC-Center eine Join-Nachricht 
sendet, die den Eintritt eines Teilnehmers in eine MC- 
Gruppe signalisiert (event- triggered), 
-ein zuvor festgelegter Timer abgelaufen ist. 

45 [0124] Denkbar ist auch der Fall, dass die MC-Nachricht, 
nachdem sie im MCC generiert wurde, nicht sofort an alle 
SGSNs gesendet wird (Vergl. 1. in Fig. 26). Stattdessen 
kann auch zuerst ein MC-Message-Request zu den SGSNs 
gesendet werden (1. in Fig. 27). 

50 [0125] Die weiteren Prozeduren zum Aufbau der Verbin- 
dungen fur die Ubertragung der MC-Nachricht vom SGSN 
zu den UEs der MC-Gruppen-Teilnehrner bleiben dann 
gleich (2. bis 7. in Fig. 27). 

[0126] Nachdem der MC-Msg.-Req. beim SGSN einge- 
55 gangen ist (7. in Fig. 27), wird nun ein Bearer (pro SGSN) 
vom SGSN zum MCC aufgebaut und es erfolgt ein MC- 
Msg.-Req. an das MCC (8. in Fig. 27). 
[0127] Erst jetzt sendet das MCC die MC-Nachricht an 
alle SGSNs, zu denen Bearer aufgebaut sind und von denen 
60 er die MC-Msg.-Req. erhalten hat (9. in Fig. 27). 

[0128] Die Ubertragung der MC-Nachricht iiber die Iu- 
Bearer zu den UEs der MC-Gruppe ist nun wieder identisch 
mit der aus Fig. 26. 

[0129] Eine weitere Moglichkeit ist, dass nach dem Ein- 
65 treffen des MC-Msg.-Rcq. beim SGSN (7. in Fig. 28) nun 
ein Bearer pro UE vom SGSN zum MCC aufgebaut wird (8. 
in Fig. 28). 

[0130] t)ber diese UE-spezifischen Bearer werden nun die 
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MC-Nachrichten iiber die SGSNs und die RNCs zu den ent- 
sprechenden UEs weitergeleitet (9. in Fig, 28). 
[0131] Darnit die Verbindungswege (Bearer) fur die Uber- 
tragung der MC-Nachrichten 7.u den einzelnen UHs einer 
MC-Gruppe nicht fiir jede einzelne MC-Nachricht einer be- 5 
summten Gruppe oder sogar bei jedem einzelnen IP-Packet 
einer MC-Nachricht neu aufgebaut werden miissen, kann 
ein Timer initiaiisiert werden. Die Verbindungen (Bearer) 
werden nun solange aufrecht erhalten, bis der Timer abge- 
laufen ist. Komrrit es zu einer emeu ten Ubertragung einer 10 
MC-Nachricht, bevor der Timer abgelaufen ist, so wird die 
MC-Nachricht iiber die noch bestehenden Verbindungswege 
iibertragen. 

[0132] Eine weitere Moglichkeit ist der Abbau der Bearer 
durch explizite Signalisierung ausgehend vom MCC, SGSN 15 
oder beiden. 

[0133] Weitere Hinweise, Definitionen, Funktionsanga- 
bcn zu den Funknctzwcrkclcmcntcn von UMTS finden sich 
insbesondere in folgenden Spezifikationen: 

20 

- 3G TS 23.002 V3.3.0, Technical Specification 
Group Services and Systems Aspects, Network archi- 
tecture, Release 1999 

- 3G TR 21.905 V3.2.0, Technical Specification 
Group Services and Systems Aspects, Vocabulary for 25 
3GPP Specifications, Release 1999 

- 3G TS 23.060 V3.4.0, Technical Specification 
Group Services and Systems Aspects, General Packet 
Radio Service (GPRS), Service description, Stage 2, 
Release 1999 30 

[0134] Folgende Abkurzungen wurden in Zusammengang 
mit der Beschreibung der Erfindung insbesondere verwen- 
det: 

[0135] Grundsatzlich: Mehrzahlbildung durch Anhangen 35 

eines 's\ z. B.: ein RB, zwei RBs 

CN: Core-Network 

GGSN: Gateway GPRS Support Node 

GPRS: General Packet Radio Service 

GSM: Global System for Mobile communications 40 

HLR: Home Location Register 

HSS: Home Subscriber Server 

IGMP: Internet Group Management Protocol 

IMSI: International Mobile Subscriber Identity 

IP: Internet Protocol 4 5 

MC: Multicast 

MCC: Multicast-Center 

MM: Mobility Management 

MS: Mobile Station 

MSC: Mobile Switching Center 50 

MSISDN: MS International ISDN Number 

PDP: Packet Data Protocoll 

PLMN: Public Land Mobile Network 

RNC: Radio Network Controller 

RNS: Radio Network Subsystem 55 
RPM: Reverse Path Multicasting 
SGSN: Serving GPRS Support Node 
SM: Session Management 
UE: User Equipment 

UMTS: Universal Mobile Telecommunication System 60 
UTRAN: UMTS Terrestrial Radio Access Network 
VLR: Velocity Location Register 

Patentanspriiche 

65 

1. Verfahren zum Verteilen einer Gruppennachricht 
(GN1) an mindestens eine Gruppe (A) von Teilnehmer- 
geraten eines Funkkommunikationssy stems (FN2), 
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wobei in mindestens einer Speichervorrichtung (SP1) 
die ein oder mehreren Teilnehmergerate der jeweiligen 
Gruppe (A) unter einer gemeinsamen Identifizierungs- 
adresse (IDA) abgelegt worden sind und dort fortlau- 
fend aktualisiert werden, wobei zur Verteilung der je- 
weiligen Gruppennachricht (GN1) durch mindestens 
ein Multicast-Center (MCC) an die Mitglieder-Teilneh- 
mergerate (UE1, UE2, UE4, UES) einer ausgewahiten 
Gruppe (A) diese zu veneilende Gruppennachricht 
(GN1) lediglich iiber einen gemeinsamen Ubertra- 
gungspfad (GP) an mindestens eine iibergeordnete 
Funknetzwerk-Kontrolleinheit (SGSN1) gesendet 
wird, mittels der Speichervorrichtung (SP1) die aktuell 
zugehorigen, zu benachrichtigenden Teilnehmergerate 
(UE1, UE2, UE4, UE5) dieser ausgewahiten Gruppe 
(A) ermittelt, und diese der ubergeordneten Funknetz- 
werk-Kontrolleinheit (SGSN1) mitgeteilt werden, und 
wobei dann von dicscr ubergeordneten Funknetzwerk- 
Kontrolleinheit (SGSN1) mindestens ein Ubertra- 
gungspfad (UP11) zur Verteilung der Gruppennach- 
richt (GN1) an die ermittelten Mitglieds-Teiinehmerge- 
rate (UE1, UE2, UE4, UE5) der ausgewahiten Gruppe 
(A) unter Zuhilfenahme einer oder mehrerer unterge- 
ordneter Funknetzwerk-Kontrolleinheiten (RNC1) be- 
reilgeslellL wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die Verteilung der Gruppennachricht (GN1) in 
einem UMTS (Universal Mobile Telecommunication 
System), GPRS (General Packet Radio Service), 
EDGE (enhanced data rates for GSM environments), 
und/oder OFDM (Orthogonal Frequency Division 
Multiplexing)-Funkkommunikauonssystem durchge- 
fuhrt wird. 

3. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als iibergeordnete 
Funknetzwerkkontrolleinheit (SGSN1) jeweils ein Ser- 
ving GPRS Support Node von UMTS verwendet wird. 

4. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als untergeordnete 
Funknetzwerkkonurolleinheit (RNC1) jeweils ein Ra- 
dio Network ConU-oller von UMTS verwendet wird. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass von der jeweiligen 
untergeordneten Funknetzwerkkontrolleinheit (RNC1) 
jeweils ein Verbindungsaufbau zu derjenigen Basissta- 
tion (BS11, BS12) ihres Versorgungsbereiches initiiert 
wird, in deren Funkzelle sich das jeweiiig zu benach- 
richtigende Teilnehmergerat (UE4) aufhalt. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass fur die Ubermitt- 
lung der Gruppennachricht (GN1) von der ubergeord- 
neten Funknetzwerkkontrolleinheit (SGSN1) zur je- 
weiiig zugeordneten, untergeordneten Funknetzwerk- 
kontrolleinheit (RNC1) lediglich ein einziger, gemein- 
samer Ubertragungspfad (GP11) aufgebaut wird. 

7. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass die mindestens eine 
Speichervorrichtung (SP1) im Funkkommunikations- 
system (FN2) zentral gefuhrt und verwaltet wird. 

8. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als Teilnehmergerat 
(UE1) jeweils ein Mobilfunkgerat, insbesondere Zellu- 
lartelefon, verwendet wird. 

9. Funkkommunikationssy stem (FN2) zum Verteilen 
cincr Gruppennachricht (GN1) an mindestens cine 
Gruppe (A) von Teilnehmergeraten, insbesondere nach 
einem der vorhergehenden Anspriiche, wobei minde- 
stens eine Speichervorrichtung (SP1) vorgesehen ist, in 
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der ein oder mehrere Teilnehmergerate (UE1, UE2, 
UE4, UE5) der jeweiligen Gruppe (A) unter einer ge- 
meinsamen Identifizierungsadresse (IDA) ablegbar 
und dort fortlaufend aktualisierbar sind, wobei minde- 
stens ein Multicast-Center (MCC) vorgesehen ist, mit 5 
dessen Hilfe bei einem Verteilungswunsch eine neue 
Gruppennachricht (GN1) an die Mitglieds-Teilnehnier- 
gerate (UE1, UE2, UE4, UE5) einer ausgewahlten 
Gruppe (A) auf einern gemeinsamen Ubertragungspfad 
(GP) an mindestens eine ubergeordnete Funknetzwerk- 10 
kontrolleinheit (SGSN1) sendbar ist, wobei die Spei- 
chervorrichtung (SP1) derart ausgebildet ist, dass die 
aktuell zugehorigen, zu benachrichtigenden Teilneh- 
mergerate CUE1, UE2, UE4, UE5) dieser ausgewahlten 
Gruppe (A) ermittelbar, und diese der ubergeordneten 15 
Funknetzwerkkontrolleinhe.it (SGSN1) mitteilbar sind, 
und wobei die ubergeordnete Funknetzwerkkontroll- 
cinhcit (SGSN1) und/odcr ihrc jcwcilig in Wirkvcrbin- 
dung stehende untergeordnete Funknetzwerkkontroll- 
einheit (RNC1) derart ausgebildet sind, dass minde- 20 
stens ein Ubertragungspfad (UP11) von dieser uberge- 
ordneten Funknetzwerkkontrolleinheit (SGSN1) zur 
Verteilung der Gruppennachricht (GN1) an die ermit- 
telten Mitglieds-Teilnehmergerate (UEL UE2 ? UE4, 
UE5) bereitslellbar ist. 25 
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